global-index.thread-num is supposed to be the maximum concurrency for global-index I/O, but the same value is applied independently at both levels: up to N bucket futures here, and each bucket starts up to N exact-file futures in bucket_search_batch. Therefore, with the default N=32, a single search can issue up to 1024 exact-file searches concurrently, and concurrent queries multiply this further. This differs from Java's shared GlobalIndexReadThreadPool, which caps the whole search at N. I reproduced this with two buckets, two files per bucket, and concurrency=2; four file searches were active simultaneously. Could we use one shared semaphore/concurrency budget across both levels, or only fan out at one level, and add a test that verifies the peak concurrency?

Thanks @JingsongLi, you're exactly right — the limit was applied independently at each level, so a single search could reach N×N concurrent exact-file reads (and concurrent queries multiplied it further).

Fixed in 5293431. Instead of two independent buffer_unordered(N) limits, the search now threads a single shared Arc<Semaphore> of N permits through the whole search, mirroring Java's single shared GlobalIndexReadThreadPool. A permit is acquired only around leaf exact-file I/O; the per-bucket orchestration never holds one, so it can't starve leaf work — the async analogue of the "start from the caller" note in PrimaryKeyVectorRead.searchBuckets. Total in-flight exact-file searches are now capped at N overall rather than per bucket, and the concurrency == 1 path stays strictly sequential.

I also added search_candidates_peak_concurrency_capped_across_buckets, which reproduces your scenario (two buckets, two files each, concurrency = 2): it instruments the exact-file search to record the peak number of simultaneously active searches and asserts it stays ≤ N. I confirmed the test observes peak = 4 and fails without the shared budget, and peak = 2 (passing) with it.